Computing systems often use a non-volatile memory device, such as a non-volatile random access memory (“NVRAM”) device, to store the system firmware. In some systems, the same NVRAM device is also utilized to store system configuration data. In systems that utilize a basic input/output system (“BIOS”) the information stored in such devices is typically information that is not accessed or modified frequently. This is generally the result of the relatively slow access times of non-volatile memory devices and of the small storage capacity of typical NVRAM devices.
With the advent and proliferation of computer systems having firmware designed around the Extensible Firmware Interface (“EFI”) specification from INTEL CORPORATION, however, it is much more common to utilize a non-volatile memory device to store data that is accessed and modified more frequently. As an example, an NVRAM device may be utilized by an EFI implementation to store an event log that includes records describing events that have occurred within the computer. Because events may occur more or less frequently, and possibly at any time while the computer is powered on, it may become necessary to read and write the non-volatile memory very frequently. However, because non-volatile memory is a relatively slow type of memory device, this type of frequent access can seriously impact performance.
In order to speed up read operations from a non-volatile memory device, a copy of all or a portion of the non-volatile memory may be kept in faster but volatile system memory. Read operations can then be performed on the copy, resulting in a faster return of desired data. For instance, a copy of an event log stored in the NVRAM may be kept in a typically faster system memory block, and read operations may be performed on the copy rather than on the slower NVRAM device. The copy of the contents of all or a portion of a slower storage device that is stored in and accessed from a faster storage device may be referred to herein as a “local copy.”
While caching all or a desired portion of an NVRAM device in faster system memory speeds up read operations, it may also create other problems. In particular, in order to read from the local copy, each software component that wants to access the local copy must have the memory address of the local copy located in volatile system memory. If the local copy is to be accessed by multiple software components, each component must obtain the memory address of the local copy in some way. If the local copy is located at a predefined fixed memory address, each software component can easily be provided the predefined fixed memory address of the local copy. For all cases described herein, though, the local copy location is not predefined.
If the memory utilized for storing the local copy is allocated dynamically, the memory address of the local copy will also be dynamic. In this case it can be difficult to provide each software component that desires to access the local copy with the newly designated memory address of the dynamically allocated local copy. This can be especially difficult where the software components that need access to the local copy are executing in different processor modes. For instance, if one software component is executing in the system management mode (“SMM”), it can be very difficult for the component to properly locate, or be passed, the information about the dynamically allocated local copy that was allocated by a component operating in protected mode.
It is with respect to these and other considerations that the various embodiments disclosed herein are presented.